- Add dotnet tools directory to PATH for subsequent steps
- Switch from --providers to --profile cpu-sampling for actual CPU profiling
- This generates flamegraphs with real stack traces instead of empty traces

Previous approach only captured runtime events (GC, JIT) without CPU samples.
The cpu-sampling profile includes Microsoft-DotNETCore-SampleProfiler which
captures stack traces at 1ms intervals, enabling proper performance analysis.

Tested locally with act - generates 22KB trace with actual profiling data.

Co-Authored-By: Claude <noreply@anthropic.com>

…rical tracking

- Add webhook workload simulation to trace real request processing
- Create analyze-trace.py script to extract performance metrics
- Implement baseline comparison against main branch via Actions cache
- Add historical performance tracking in perf-history/ directory
- Display performance reports in GitHub Actions summary
- Upload metrics artifacts with 30-day retention

This provides actionable performance insights and trend tracking
over time, enabling early detection of performance regressions.

The analyze-trace.py script was only parsing the 'sampled' profile
format (samples/weights arrays), but dotnet-trace produces 'evented'
format (open/close events with timestamps). This caused the script to
extract 0 samples from valid trace files.

Changes:
- Add support for evented profile type with O/C event parsing
- Track stack state and calculate frame durations from events
- Fix deprecated datetime.utcnow() usage
- Maintain backward compatibility with sampled format

The evented format is parsed by tracking open/close events to
reconstruct the call stack and measure time each frame spent active.
This produces accurate hotspot metrics from dotnet-trace output.

Significantly improved readability and usability of performance trace reports:

**Readability Improvements:**
- Human-readable time formats (41.6 min vs 2498937ms)
- Visual progress bars for percentages using block characters
- Clear verdict at top (✅/⚠️/🔴) based on baseline comparison
- Collapsible sections to reduce information density

**Balanced View:**
- Show verdict + key metrics prominently
- Filter application hotspots from framework noise
- Categorize methods as app/framework/noise with emoji badges
- Full technical details available in collapsible sections

**New Features:**
- format_duration(): Convert ms to readable format
- format_percentage_bar(): Create visual █░ progress bars
- categorize_method(): Detect ProbotSharp app code vs framework
- Improved baseline comparison with trend indicators (↑↓→)
- Contextual help: "Changes within normal variance" guidance

**User Experience:**
- Before: Dense technical table, unclear if performance is good/bad
- After: Clean verdict, visual bars, filtered hotspots, actionable insights

Tested with real trace files - output is much more scannable and actionable.

…nalysis

Fixed critical bug where script summed inclusive times instead of calculating
exclusive times, causing massive overcounting (30s trace showed as 41 minutes).

Changes:
- Implemented stack-based exclusive time calculation for evented format
- Track both inclusive (total) and exclusive (self) time per frame
- Calculate wall-clock duration as max(profile durations), not sum
- Total CPU time = sum of exclusive times across all frames
- Update all output fields to use new metric names

Metrics:
- wall_clock_ms: Actual elapsed time (endValue - startValue)
- total_cpu_time_ms: Sum of all exclusive times
- Methods show both inclusive_ms and exclusive_ms
- Percentages calculated against wall_clock, not summed times

Verification:
Before: 2,498,937 ms (41 minutes) - WRONG
After: 30,016 ms (30 seconds) - CORRECT

The fix follows industry best practices (Brendan Gregg, Speedscope) for
calculating exclusive time: exclusive = inclusive - children_time.